


nix 


from a build system to an ansible replacement 








build system 


edit : main.o command.o display.o insert.o utils.o 
CC -0 edit main.o command.o display.o insert.o utils.o 


main.o : main.c defs.h 
CC -c main.c 

command.o : command.c defs.h command. h 
CC -c command.c 

display.o : display.c defs.h buffer.h 
CC -c display.c 

insert.o : insert.c defs.h buffer.h 
CC -c insert.c 

utils.o : utils.c defs.h 
CC -c utils.c 








build system 


uütils.o : utils.c defs.h 
cc -c utils.c 


target : prerequisites 
recipe 


prerequisites are referenced in the recipe, thus should be considered part of the recipe 
target is the consequence of the recipe, thus should be a function of the recipe 








build system 


lets name the minimal unit of a build as: derivation 
(disclaimer: codes bellow are just rough approximations of how nix really works) 


utils.o : utils.c defs.h 
cc -c utils.c 


derivation { 
builder = “cc =c utils:c"; 


Ir 
name the output 


# evaluate the derivation, and normalize it 
"builder": "cc -c utils.c"} 

# then we hash the normalized derivation string 
0y876lqq57qyb4x5J01374zl3gifwqa3nnc4q603gc2jnd42rfr6 
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to ensure the reproducibility of nix derivations, we also have to track the inputs 
a natural design is that every input must be the output of another derivation 


cc = derivation { ... | 
ütils.c = derivation 10h 
utils.o = derivation { 

builder cc CE MI Mec 
Hn 


# which is normalized into 
{"builder": "0ssiiwpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndqili -c 0jbrxcbbrdvfpwljhcw7mr64hln8l9ccm... "} 


take notice of the implicit input: defs.h, which is likely to be missed by other build systems 
nix build derivations in sandboxes in which only the referenced pathes can be reached 
no more unexpected build failures 
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relative paths are inherently ambiguous 
thus we replace them with absolute pathes, by prepending a common prefix: the nix store 


{"builder": "/nix/store/0ssilwpaf7plaswqqjwigppsg5fyh99vdlb9kz17c9lng89ndqli -c /nix/store/0jbrxcbbrdv ... "} 


everytime any of the inputs of a derivation is changed, wether it's the compiler or a source file 
the derivation itself is changed, thus the inputs are tracked effectively and reliably 
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NIX 


further enhancment to nix derivations 


CE = derivation { ... F}; 
utils:c = derivation 1 2... 7. 
utils.o = derivation { 
# hashes are nice for machines, not humans (name is appended to the original hash) 
name ASTI ee oS 
# we can tell the builder where to put our output at build time 
builder = "$fcc} o $out -c ${utils.c}"; 
# the platform, on which the derivation could be build 


system = "x86 64-linux"; 
# extra key value pairs that would be passed to the builder as envvars 
foo Rea 
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and expand the definition of derivation output from a single file, to a tree 


I— bin 


| — ee 


I— include 
| tice 


but how do we hash a tree of files 
we can first combine them into a tarball then hash the tarball 
however tar is not deterministic, thus we serialize it into Nix ARchive, a deterministic archive format 








build system 


not all files are built, some are just lying around, for example, utils.c 
we treat them specially and give them the name: fixed output derivations (or FOD) 
their path is not the hash of the derivation itself, but rather the hash of it's output 


derivation { 


name pu scu 

builder - "none"; 

system = "Xx86_64-linux"; 

outputHash = "0jbrxcbbrdvfpwljhcw7mr64hln8l9ccmpydb680n9wp3mm974sd" ; 


Di 


as FODs have fixed output hashes, they can be built outside of the sandbox 
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and, we add a syntax sugar into the nix language: you can reference a local path as a derivation 
which will be copied into the nix store at evaluation time, and transformed into a FOD 


cc = derivation { ... f; 
utils.o = derivation { 
name nia sone 
src =a UIl. C; 
builder = "${cc}/bin/cc -o $out -c $src"; 
system = "x86_64-linux"; 








build system 


binary caches 
given a derivation, we know that it will be realized into the same output 


whenever, wherever 


never build software more than once 


we can serve our nix store as a binary cache 
to reuse store pathes across machines 


there's no need to build the same chromium variant twice 








build system 


=» derivation is the smallest unit of compilation in nix, Just like a rule in makefile 

=» derivation is the combination of what and how to build the output 

=» the inputs of a derivation must be derivations 

=» the absolute path of the output is determined by hashing the derivation's normalized form, before building 
=» derivations are built in sandboxes with no network access and only access to required pathes 

=» a special type of derivation: FOD exists, to bring in sources as derivations 


=» build results can be shared as binary caches, eliminating the need for duplicated builds 








build system 


nix is a build system, but most of the existing projects are already using other build systems 
let me introduce: generic builders, which bridges the gap between nix and them 


builder = '' 


for dep in $deps; do 
export PATH=$dep/bin: $PATH 
done 


tar -xf $src 

./configure --prefix=$out 
make 

make install 


hello = derivation { 


name = "hello"; 

Src = ./hello.tar.gz; 
builder = builder; 

system = "x86 64-linux"; 
deps = [| gcc gnumake ... | 
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rust, golang, c++, python... 

there are so many languages and frameworks 
can we unite the efforts in building softwares 
thus we have nixpkgs 


The Nix Packages collection (Nixpkgs) is a set of thousands of packages for the Nix package manager, released under a permissive 
MIT/X11 license. Packages are available for several platforms, and can be used with the Nix package manager on most GNU/Linux 


distributions as well as NixOS. 


nixpkgs provides not only the compiler toolchains as a basis for other packages, but also infrastructures for 
packaging applications written in various languages and frameworks 
and 
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NIX 
a real life example of building a golang package 


i fetchgit, buildGoModule, fetchFromGitHub, lib }: 
buildGoModule rec { 
pname = "kQsctLl"; 
version = "v0.8.4"; 
src = fetchgit { 
url = "https://github.com/k0sproject/k0sctl" ; 
rev = "v0.8.4"; 
sha256 = "08k0aa73kb4hs4z18a2nmasag0czmppb2r0s1af]287c2a4ynw73"; 
t 
vendorSha256 = "sha256-8GFZxjkLeTGWxJ3uzaPZaeeJzmmPN9A03z8a3JooP0s-" ; 
subPackages - | "." ]; 
meta - with lib; 1 
homepage = "https: //github.com/k0sproject/k0sctl" ; 
license = licenses.asl20; 


kt 
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NIX 
and | hear gentoo users screaming: where are my use flags 


{ fetchurl, fetchpatch, lib, stdenv, pkg-config, libgcrypt, libassuan, libksba 
, libgpgerror, libiconv, npth, gettext, texinfo, buildPackages 
, guiSupport ? true, pinentry ? null }: 
stdenv.mkDerivation rec { 
pname = "gnupg"; 
version =~ 2.2.27; 
src - fetchurl 1 
url = "mirror://gnupg/gnupg/${pname}-${version}.tar.bz2"; 
sha256 = "1693s2rp9sjwvdslj94n03wnb6rxysjy0dli0g1698af044h1ril"; 
n 
nativeBuildInputs = | pkg-config texinfo ]; 
buildInputs = | 
libgcrypt libassuan libksba libiconv npth gettext 
readline libusb1 gnutls adns openldap zlib bzip2 sqlite 
I} 
pinentryBinaryPath = pinentry.binaryPath or "bin/pinentry"; 
configureFlags = | 
"--with-libgpg-error-prefix=${libgpgerror.dev}" 
] + optional guiSupport "--with-pinentry-pgm=${pinentry}/${pinentryBinaryPath}"; 








package manager 


being able to build packages in a reproducible, declarative and reliable manner is great 
but it makes little sense if we cannot install them 
which, is the role of a package manager 








package manager 


the build time dependencies are explicitly specified 

and the runtime dependencies are automatically recognized 
by serializing the store path into Nix ARchive 

then search for references to other store pathes within it 


$ nix-store -q --references /nix/store/x64nf80gzcq6v5j1isnnkvwd73n9v4sy-nano-5.7 
/nix/store/sbbifs2ykc05inws26203h0xwcadnfOül-glibc-2.32-46 
/nix/store/9m4hy7cy70w6v2rqjmhvd7ympqkj6yxk-ncurses-6.2 
/nix/store/x64nf80gzcq6v5j1isnnkvwd73n9v4sy-nano-5.7 


by searching for references recursively, we can form a closure of the package to install 
that is, itself and all it's direct and transitive runtime dependencies 








package manager 


when we want to install a derivation 
there are generally two possibilities 


1. the closure is already in the store or available from a binary cache 


2. it has to be built 


the first case is trivial, for the second case, we build it, then we infer the closure 
now that it's already in the nix store, we only have to create a view of the nix store to make it accessible 


activation = "export PATH=${hello}/bin:${nano}/bin"; 


a new concept: activation script 
activation script is an idempotent shell script the bring whatever in the nix store into life 


for the example above, we may as well symlink all the packages to install, into /usr/bin 
mimicking the behavior of traditional package managers 
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advantages over traditional package manager 


= pno SAT solver 

=» install multiple versions or variants of the same package together 
=» no assumptions about the global state of the system 

=» no replace file in-place 


=» no worry about kernel panic midway a upgrade 
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winget can only install packages for now, but not remove them 





garbage collection to the rescue 

when we install a derivation, we register it as a gcroot 

when we remove it, we deregister it 

periodically, we walk through all reachable store pathes from the gcroots 
then we can safely remove the unreachable pathes 








operating system 


an operating system is a collection of packages, and their configurations 


p boot 

I— etc 

— Wis 
I— bin 
I— include 
p Lele 


L— share 
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why there must be an an artificial separation between packages and configurations 


p lene 
L— nix 

I — store 

| I— zzbgphmiv31zfi7x3hvjdwlxj3kl9vg-activate 
L— zzvqb5qwlim2xikawfqxb0q8gl2bw391a9-foo 

po eal 

I — share 

I— include 

L— lib 


| 
| 
| 
| 
| 
L— var/nix/profiles/system/activate -> /nix/store/zzbgphm1v31zfi7x3hvjdwlxj3kl9vg-activate 
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{ config, pkgs, ... }: 1 
boot.loader.systemd-boot.enable - true; 
boot.kernel.sysctl = { 


"kernel.panic" = 10; 
"kernel.sysrq" = 1; 
Inr 
boot.kernelParams = [| 
"quiet" 


"mitigations-off" 
I 
fileSystems."/".device.label = "nixos"; 
environment.systemPackages = with pkgs;| git gnupg rustc ]; 
services.sshd.enable - true; 


declaratively config your operating system, from the bootloader, to every running service 
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expand the configuration of a single host, to a fleet of hosts 


- name: configure db servers 
hosts: databases 
remote user: root 
tasks: 
- name: ensure that postgresql is started 
ansible.builtin.service: 
name: postgresql 
state: started 


{£ confie, pkes Ub S58 jee at 
services.postgresql.enable = true; 

} 

i confie, pkes, lib, =. F: l 


imports = [ ./postgresql.nix ]; 








configuration management 


the power of nixos roots in the nix language 


=» validate configuration fields before deployment 
=» reference values across modules of configuration 
=» reuse configuration efficiently 


=» unified language for any system component 
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NIXOS 

{€ pkgs, config, =.. J: 

let 
socketPath = "${config.services.traefik.dataDir}/podman.sock"; 

in 

i 
virtualisation.oci-containers.backend - "podman"; 
virtualisation.oci-containers.containers = { ... }; 


systemd.services.podman-traefik.serviceConfig.ExecStart = '' 
${pkgs.socat}/bin/socat \ 
UNIX-LISTEN:${socketPath} \ 
UNIX-CONNECT: /run/podman/podman. sock 


rt 
LÀ 


services.traefik = { 
enable = true; 
staticConfigOptions = { 
providers.docker = { 
endpoint = "unix://${socketPath}"; 








for the curios 


hail hydra ! 


nixos.org 


still want to dive deeper 


nix pills 


how to get something done 


nix.dev 


telegram group 


@nixos_zhcn 





